Mobility across satellite beams using L2 connectivity

ABSTRACT

Systems and methods for providing mobility across satellite beams, are described. The system includes a first core node, a second core node in communication with the first core node at layer-2 of the OSI model (L2), and a first gateway in communication, at L2, with the first core, the first gateway configured to provide access to a first spot beam at a first location. The system further includes a second gateway in communication, at L2, with the second core node, the second gateway configure to provide access to a second spot beam at a second location, and a mobile device, at the first location, in communication with the first gateway via the first spot beam, wherein the mobile device is assigned an IP address by the first core node. The mobile device moves from the first location to the second location. Further, the first gateway, in response to the mobile device moving from the first location to the second location, notifies the second gateway, through the first core node and the second core node, that the mobile device is moving to the second location, and transmit the session information to the second gateway, and the second gateway, in response to the notification, maintains connectivity with the mobile device using the IP address.

PRIORITY CLAIM

This application is a continuation of U.S. patent application Ser. No.14/994,957, entitled “Mobility Across Satellite Beams Using L2Connectivity” filed Jan. 13, 2016, which is a continuation of U.S.patent application Ser. No. 13/889,021, entitled “Mobility AcrossSatellite Beams Using L2 Connectivity,” filed May 7, 2013, which is acontinuation of U.S. patent application Ser. No. 12/761,904, entitled“Mobility Across Satellite Beams Using L2 Connectivity,” filed Apr. 16,2010, which claims the benefit of U.S. Provisional Patent ApplicationSer. No. 61/170,359, entitled “Mobility Across Satellite Beams Using L2Connectivity,” filed Apr. 17, 2009 and U.S. Provisional PatentApplication Ser. No. 61/316,776, entitled “Mobility Across SatelliteBeams Using L2 Connectivity,” filed Mar. 23, 2010. The entirety of eachof the above-identified applications are expressly incorporated byreference herein for any and all purposes.

RELATED APPLICATIONS

This application is related to: U.S. Provisional Application No.61/254,551, entitled “Layer-2 Connectivity From Switch to AccessNode/Gateway,” filed on Oct. 23, 2009; U.S. Provisional Application No.62/254,553, entitled “Access Node/Gateway to Access Node/Gateway Layer-2Connectivity (End-to-End),” filed on Oct. 23, 2009; U.S. ProvisionalApplication No. 62/254,554, entitled “Layer-2 Extension Services,” filedon Oct. 23, 2009; U.S. Provisional Application No. 61/313,017, entitled“Core-based Satellite Network Architecture,” filed on Mar. 11, 2010;U.S. Provisional Application No. 61/316,782, entitled “Multi-SatelliteArchitecture” filed on Mar. 23, 2010, and U.S. Provisional ApplicationNo. 61/316,791, entitled “Acceleration Through a Network Tunnel,” filedon Mar. 23, 2010. The entirety of each of the above-identifiedapplications are expressly incorporated by reference herein for any andall purposes.

FIELD OF THE INVENTION

The present invention relates, in general, to mobility in satellitenetworks, and more particularly, to mobility at layer-2 of the OSImobile across multiple satellite beams.

BACKGROUND OF THE INVENTION

Presently, for mobile IP implementations each mobile device isidentified by its home address (i.e. at the mobile device's home agent)regardless of the mobile's device's current location. While the mobiledevice is away from its home network, the mobile device is assigned acare-of address. The care-of address identifies the mobile device'scurrent location. The care-of address acts as a local endpoint of atunnel back to the mobile device's home agent, and the home address. Assuch, mobile IP specifies how the mobile device registers with its homeagent and how the home agent routes data to the mobile device throughthe tunnel (between the home argent and the care-of address).

Mobile IP has significant drawbacks. One drawback is when the mobiledevice moves out of its home location, the mobile device's care-ofaddress is a virtual address. Hence, moving out of the home locationrequires a hand off, which changes the mobile device's IP address byadding a care-of-address. This is particularly problematic in IPv4networks. Thus, connectivity is temporarily lost, browser session islost, VPN session is lost, etc. In many applications (e.g., VPN, VoIP),sudden changes in network connectivity and IP address causes significantproblems. For example, an SSL tunnel for on-line banking will terminate.Furthermore, the tunnel between the home address and the care-of addressis a layer=3 protocol, and as such, the mobile device moves out of itshome location the mobile device is no longer connected to the samenetwork (i.e., LAN, subnet, etc.). Additionally, traffic must be routedthrough the home agent location. For example, if the mobile device andthe data the mobile device is accessing are at the same remote location,the data must travel all the way to the home agent location and thencircle back to the remote location, thus greatly increasing latency.Accordingly, current mobile IP implementations fail to provide apersistent IP address and persistent connectivity and efficient datatransfer over a large geographical area. Hence, for these and otherreasons, improvements in the art are needed.

SUMMARY OF THE INVENTION

In one embodiment, a system for providing mobility across satellitebeams, is described. The system includes a first core node, a secondcore node in communication with the first core node at layer-2 of theOSI model (L2), and a first gateway in communication, at L2, with thefirst core, the first gateway configured to provide access to a firstspot beam at a first location. The system further includes a secondgateway in communication, a L2, with the second core node, the secondgateway configure to provide access to a second spot beam at a secondlocation, and a mobile device, at the first location, in communicationwith the first gateway via the first spot beam, wherein the mobiledevice is assigned an IP address by the first core node. The mobiledevice moves from the first location to the second location. Further,the first gateway, in response to the mobile device moving from thefirst location to the second location, notifies the second gateway,through the first core node and the second core node, that the mobiledevice is moving to the second location, and transmits the sessioninformation to the second gateway, and the second gateway, in responseto the notification, maintains connectivity with the mobile device usingthe IP address.

In another embodiment, a method of providing mobility across satellitebeams, is described. The method includes providing access to a firstspot beam at a first location serviced by a first gateway, providingaccess to a second spot beam at a second location serviced by a secondgateway, and assigning a mobile device, at the first location, an IPaddress by the first gateway. The mobile device moves from the firstlocation to the second location. The method further includes in responseto the mobile device moving from the first location to the secondlocation, notifying the second gateway, through a first core node and asecond core node, that the mobile device is moving to the secondlocation, transmitting the session information to the second gateway andin response to the notification, maintaining connectivity with themobile device using the IP address.

In yet another embodiment, a computer-readable medium for providingmobility across satellite beams, is described. The computer-readablemedium includes instructions for providing access to a first spot beamat a first location serviced by a first gateway, providing access to asecond spot beam at a second location serviced by a second gateway, andassigning a mobile device, at the first location, an IP address by thefirst gateway. The mobile device moves from the first location to thesecond location. The computer-readable medium further includesinstructions for in response to the mobile device moving from the firstlocation to the second location, notifying the second gateway, through afirst core node and a second core node, that the mobile device is movingto the second location, transmitting the session information to thesecond gateway and in response to the notification, maintainingconnectivity with the mobile device using the IP address.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of the presentinvention may be realized by reference to the remaining portions of thespecification and the drawings wherein like reference numerals are usedthroughout the several drawings to refer to similar components. In someinstances, a sublabel is associated with a reference numeral to denoteone of multiple similar components. When reference is made to areference numeral without specification to an existing sublabel, it isintended to refer to all such multiple similar components.

FIG. 1 shows a block diagram of one embodiment of a gateways within asatellite communications networks.

FIG. 2 shows a block diagram of an embodiment of an autonomous gateway,according to various embodiments of the invention.

FIG. 3 shows a block diagram of an embodiment of a non-autonomousgateway, according to various embodiments of the invention.

FIG. 4A shows a block diagram of a core node within a satellitecommunications network, according to various embodiments of theinvention.

FIG. 4B shows a block diagram of an alternative embodiment of a corenode within a satellite communications network, according to variousembodiments of the invention.

FIG. 5A shows a block diagram of one embodiment of a core nodearchitecture for a satellite communications network, according tovarious embodiments of the invention.

FIG. 5B shows a block diagram of one embodiment of flow of a core nodearchitecture for a satellite communications network, according tovarious embodiments of the invention.

FIG. 6 shows a block diagram of one embodiment of a geographic topologyfor a core node architecture within a satellite communications network,according to various embodiments of the invention.

FIG. 7 shows a block diagram of one embodiment of a network forimplementing mobility across spot beams, according to variousembodiments of the invention.

FIG. 8 shows a block diagram of a further embodiment of a network forimplementing mobility across spot beams, according to variousembodiments of the invention.

FIG. 9 shows a flow diagram of a method of implementing mobility acrossspot beams, according to various embodiments.

FIG. 10 is a simplified block diagram illustrating the physicalcomponents of a computer system that may be used in accordance with anembodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The ensuing description provides exemplary embodiment(s) only, and isnot intended to limit the scope, applicability or configuration of thedisclosure. Rather, the ensuing description of the exemplaryembodiment(s) will provide those skilled in the art with an enablingdescription for implementing an exemplary embodiment, it beingunderstood that various changes may be made in the function andarrangement of elements without departing from the spirit and scope asset forth in the appended claims. Some of the various exemplaryembodiments may be summarized as follows.

Aspects of the invention include providing mobility among multiplesatellite beams. Particularly, a mobile device (or client) is able tomove among satellite and maintain the same consistent IP address.Furthermore, the mobile device is able to remain within the same network(i.e., LAN, subnet, etc.) while moving through coverage of multiplesatellite beams. Aspects of the invention are realized, in part, due toend-to-end layer-2 connectivity throughout the ground segment network.

FIG. 1 illustrates a gateway 105 a in communication with a gateway 105b. further, gateways 105 a and 105 b are in communication with theInternet 125. The gateways 105 receive requests at a satellite modemtermination system (SMTS) 120. The SMTS 120 sends the request to alayer-3 switches 110 (a and b).

As used herein, a “routed network” refers to a network having a numberof routers, configured to use protocols at layer-3 and above of the OSIstack (e.g., or substantially equivalent types of protocols) to routedata through the network. The layer-3 switch as used herein, is intendedto broadly include any type of network device configured to route atlayers 3 and above of the OSI stack (e.g., or provide substantiallysimilar network layer functionality). Particularly, routing is intendedto be distinguished from switching (e.g., at layer 2 of the OSI stack(e.g., or substantially similar functionality), as will become moreclear from the description below.

While utilizing higher layers to route communications may providecertain features, such as enhanced interoperability, it may also limitcertain capabilities of the network. As one exemplary limitation, ateach node where a layer-3 routing decision is made, determining theappropriate routing may involve parsing packets headers, evaluatingparsed header information against routing tables and port designations,etc. These steps may limit the type of traffic that can be sent over thenetwork, as well as the protocols available for transport on thenetwork.

In another exemplary limitation, at each router, layer-2 headers aretypically stripped off and replaced with other tags to identify at leastthe next routing of the data through the network. As such, it isimpossible to maintain a single network between routed terminals. Inother words, a packet which is generated at one LAN, passes through oneor more routers (i.e. at layer-3 or above) and is received at anotherLAN, will always be considered to be received from a different network.Accordingly, any benefit of a single network configuration isunattainable in a layer-3 routed network. For example, tags forsupporting proprietary service providers networks, Multiprotocol LabelSwitching (MPLS), and/or other types of networks are impossible tomaintain across large geographic regions (e.g., multiple LANs, WANs,subnets, etc.).

For example, CPEs (not shown) and other client devices connected togateway 105 a could not be located on the same network (e.g., same LAN,subnet, etc.) as CPEs connected to gateway 105 b. In other words, once apackets from layer-3 switch 110 a were sent to layer-3 switch 110 b, thepackets would no longer be considered to be on the same network (e.g.,LAN, subnet, etc.) as gateway 105 a's network. Accordingly, virtualnetworking protocols such as, VPN, MPLS, etc., must be used for sendingtraffic between gateway 105 a and 105 b. Furthermore, depending on thetype of service if the service or services fail on gateway 105 a, thengateway 105 b may be unable to provide the failed service or services toCPEs connected to gateway 105 a (the two gateways are, from a networkingprospective, isolated). However, if the traffic between gateway 105 aand 105 b was switched at layer-2, then gateway 105 b would be able toprovide the failed service or services to the CPEs connected to gateway105 a.

FIG. 2 show an embodiment of an autonomous gateway 205, according tovarious embodiments of the present invention. In some embodiments, theautonomous gateway 205 includes one or more SMTSs 215 (a-d), whichimplements substantially as the SMTSs 215 of the non-autonomous gateway305 of FIG. 3. The SMTSs 215 may be in communication with one or moremultilayer switches 210 a and 210 b. The multilayer switches 210 a and210 b may be in communication with a gateway module 250, and may also bein communication with the Internet 125, CDN/CSN networks 240, orMPLS/VPLS networks 245. The multilayer switches 210 a and 210 b may beconfigured to process data to and from one or more modules. For example,the multilayer switches 210 a and 210 b may be in communication withservices module 220, acceleration modules 225, provisioning modules 230,and/or management modules 235. It will be appreciated that, unlike thegateway 105 of FIG. 1, in accordance with aspects of the presentinvention, embodiments of the autonomous gateway 205 are able toimplement some of the enhanced functionality of the non-autonomousgateways 305 and core node 405.

In one embodiment, autonomous gateway 205 is configured to operateautonomously or separately from other gateways and/or core nodes. Forexample, using services module 220, acceleration modules 225,provisioning modules 230, and management modules 235, autonomous gateway205 is able to completely manage requests received through SMTSs 215 andmultilayer switches 210 a and 210 b. Furthermore, since multilayerswitches 210 a and 210 b are equipped to handle requests at both layer-2and layer-3, autonomous gateway 205 is not limited in the same ways asgateway 105.

In one embodiment, services module 220 may include services, such as,AAA, RADIUS, DHCP, DNS, TFTP, NTP, PKE, etc. furthermore, managementmodules 235 may include billing, terminal, shell, IP flow informationexport (IPFIX), traffic and/or flow accounting and analysis, SNMP,syslog, etc. Accordingly, autonomous gateway 205 is equipped to functionas a “stand-alone” entity, locally (or pseudo-locally) providingservices and management to CPEs.

Turning now to FIG. 3, illustrating an embodiment of a non-autonomousgateway 305, in accordance with embodiments of the present invention.The non-autonomous gateway 305 may include a number of SMTSs 215 (a-d).Embodiments of each SMTS 215 include multiple base stations (not shown).For example, each base station may be implemented on a circuit card orother type of component integrates into the SMTS 215. The illustratednon-autonomous gateway 305 includes four SMTSs 215, each incommunication with two layer-2 switches 310 a and 310 b. For example,each SMTS 215 is coupled with both layer-2 switches 310 a and 310 b toprovide redundancy and/or other functionality. Each layer-2 switch 310may then be in communication with a core node 405.

Embodiments of the non-autonomous gateway 305 are configured to supportminimal functionality and provide minimal services. Unlike theautonomous gateway 205, non-autonomous gateway 305 does not includeservices module 220, acceleration modules 225, provisioning modules 230,and management modules 235. Hence, non-autonomous gateway 305 simpledesign requires minimal management and maintenance, as well as asignificantly lower cost than the autonomous gateway 205. Non-autonomousgateway 305 is configured to send and receive communications throughSMTSs 215 a-d (e.g., to and from a satellite) and similarly send andreceive communications through layer-02 switches 310 a and 310 b (e.g.,to and from core node 405).

FIG. 4 illustrates a core node 405, in accordance with one embodiment ofthe present invention. Core node 405 may be in communication with 1 to Nnon-autonomous gateways 305. As discussed above, the non-autonomousgateways 305 communicate with the core node 405 using layer-2connectivity between one or more layer-2 switches 310 in thenon-autonomous gateways 305 and one or more multilayer switches 420 aand 420 b in the core node 405. The illustrative core node 405 is incommunication with multiple non-autonomous gateways 305 a-305 n viamultilayer switches 420 a and 420 b. In various embodiments, themultilayer switches 420 a and 420 b are in communication with each othereither directly or indirectly (e.g., via a gateway module 250).

In some embodiments, the gateway module 250 includes one or moreprocessing components for processing traffic received at the multilayerswitches 420 a and 420 b. In one embodiment, the gateway module 250includes a traffic shaper module 415. The traffic shaper module 415 is aservice which is configured to assist in optimizing performance ofnetwork communications (e.g., reduce latency, increase effectivebandwidth, etc.), for example, by managing packets in a traffic streamto conform to one or more predetermined traffic profiles.

The multilayer switches 420 a and 420 b may further be in communicationwith one or more of the Internet 125, CDN/CSN networks 240, andMPLS/VPLS networks 245. In some embodiments, the core node 405 includesan interface/peering node 465 for interfacing with these networks. Forexample, an Internet service provider or CDN service provider mayinterface with the core node 405 via the interface/peering node 465.

Embodiments of the multilayer switches 420 a and 420 b process data byusing one or more processing modules or interfaces in communication withthe multilayer switches 420 a and 420 b. For example, as illustrated,the multilayer switches 420 a and 420 b may be in communication withAA/RADIUS 435 a, DHCP/DNS 435B, TFTP/NTP 435 c, or PKI 435 d, through afirewall 410 and services interface 430. Furthermore, multilayerswitches 420 a and 420 b may be in communication with a provisioningmodule 455 through a firewall 440, a layer-2 switch 445, and amanagement interface 450. In addition to being in communication withprovisioning module 455, multilayer switches 420 a and 420 b may also bein communication with policy module 460 a, AAA/RADIUS 460 b,terminal/shell 460 c, IP flow information export (IPFIX), traffic and/orflow accounting and analysis 460 d, SNMP/syslog 460 e, and TFTP/NTP 460f Communication with these modules may be restricted, for example,certain modules may have access to (and may use) private customer dataproprietary algorithms, etc., and it may be desirable to insulate thedata from authorized external access. In fact, it will be appreciatedthat many types of physical and/or logical security may be used toprotect operations and data of the core node 405. For example, each corenode 405 may be located within a physically secured facility, like aguarded military-style installation.

In a further embodiment, services interface may be communication withservice 1 432 a to service N 432N. Service 1 to service N may be any oneof the services described above (i.e., AAA/RADIUS 345 a, DHCP/DNS 435 b,TFTP/NTP 460 f, etc.), as well as other services provided in satellitenetworking environment. Furthermore, any number of services may beprovided (i.e., 1-N number of services).

In one embodiment, the acceleration modules 225 include beam-specificacceleration modules and a failover module which detects a connectionfailure and redirects network traffic to a backup or secondaryconnection. Embodiments of the acceleration modules 425 provide varioustypes of application, WAN/LAN, and/or other acceleration functionality.In one embodiment, the acceleration modules 425 implement functionalityof AcceleNet applications from Intelligent Compression Technologies,Inc. (“ICT”), a division of ViaSat, Inc. This functionality may be usedto exploit information from higher layers of the protocol stack (e.g.,layers 4-7 of the OSI stack) through use of software of firmwareoperating in each beam-specific acceleration module. The accelerationmodules 425 may provide high payload compression, which may allow fastertransfer of the data and enhances the effective capacity of the network.In some embodiments, certain types of data (e.g., User Datagram Protocol(UDP) data traffic) bypass the acceleration modules 425, while othertypes of data (e.g., Transmission Control Protocol (TCP) data traffic)are routed through the accelerator module 350 for processing. Forexample, IP television programming may bypass the acceleration modules425, while web video may be sent to the acceleration modules 425 fromthe multilayer switches 420 a and 420 b.

In one embodiment, the AAA/Radius module 460 b may implementfunctionality of an Authentication Authorization Accounting (AAA)server, a Remote Authentication Dial-In User Service (RADIUS) protocol,an Extensible Authentication Protocol (EAP), a network access server(NAS), etc. Embodiments of the DHCP/DNS module 435 b may implementvarious IP management functions, including Dynamic Host ConfigurationProtocol (DHCP) interpretation, Domain name System (DNS) look-ups andtranslations, etc. Embodiments of the TFTP/NTP module 435 c mayimplement various types of protocol-based functions, including filetransfer protocols (e.g., File Transfer Protocol (FTP), trivial filetransfer protocol (TFTP), etc.), synchronization protocols (e.g.,Network Time Protocol (NTP)), etc. Embodiments of the PKI module 435 dimplement various types of encryption functionality, includingmanagement of Public Key Infrastructures (PKI), etc.

In a further embodiment, policy module 460 a may control certain billingfunctions, handle fair access policies (FAPs), etc. Embodiments of theterminal/shell module 640 c may implements various types of connectivitywith individual devices. Embodiments of the SNMP/Syslog module 460 e mayimplement various network protocol management and logging functions. Forexample, the SNMP/Syslog module 460 e may use the Simple NetworkManagement Protocol (SNMP) to expose network management information andthe Syslog standard to log network messages.

In an alternative embodiment, FIG. 4B illustrates traffic shaper module415 operating separately from gateway module 250. In this configurationtraffic shaper module 415 may be locally or remotely located fromgateway module 250, and may communicate directly with multilayerswitches 420 a and 420 b, or with gateway module 250.

Accordingly, core node 405 is configured to internally handle variousservices and functionality. Turning now to FIG. 5A, which illustratesone embodiment of a core-based network architecture 500, implementing acore 505 which includes core nodes 405. In one embodiment, each corenode 405 a-d is connected to every other core node, and each core node405 a-d is connected to a non-autonomous gateway 305 a-d, respectively.The configuration is merely for the purposes of explanation, and itshould be noted that any number of core nodes or non-autonomous gatewaysmay be used. Also, core nodes may be indirectly connected to other corenodes, core nodes may be connected to other core nodes through one ormore non-autonomous gateway, etc.

Such a network configuration provides significant benefits. For example,service and/or resource specific failure at a core node, or completefailure of a core node is able to be redundantly managed by one or moreof the other core nodes. Assuming, for the purpose of explanation, thatcore node 405 a services non-autonomous gateway 305 a, core node 405 bservices non-autonomous gateway 305 b, and so forth. If, for example,DHCP service at core node 405 b fails, then DHCP service requests fromthe customers connected with non-autonomous gateway 305 b would beserviced through core node 405 d, without the customers noticing anychange. For example, their IP address, their session, etc., would remainthe same. Furthermore, the other services provided by core node 405 b(e.g., DNS, acceleration, PKI, etc.) would still be handled by core node405 b, and only the failed service would be diverted to core node 405 d.

Such a service specific redundancy scheme is possible by this networkconfiguration, in part, because of the end-to-end layer-2 connectivity,the placement of the core nodes, and structure and configuration of thecore nodes 405. For example, if the network did not have end-to-endlayer-2 connectivity, then such redundancy would not be possible. If thepackets were routed (i.e., layer-3 or above), or virtually switched(i.e., MPLS), then once a packet went from core node 405 b to core node405 d, the MAC header of the packet would be altered, and as such thenetwork (i.e., the LAN, subnet, etc.) of the packet would change.Accordingly, the ability to provide service through the new core node(e.g., core node 405 d) would be lost.

Similarly, if a core node completely fails or the connection (e.g.,fiber cable) between a core node and a non-autonomous gateway fails,then all of the operations of the failed core node are able to beassumed by (or diverted to) one or more other core nodes. For example,if the connection between non-autonomous gateway 305 a and core node 405a is cut or damaged, then core node 405 c may provide the servicespreviously provided by core node 405 a to non-autonomous gateway 405 a.In one embodiment, in both examples the core node assuming the failedservice in response to a complete failure may be notified of the failureby, for example, time-to-live (TTL) packets, acknowledgment packets,etc. If the core node's functions fall below a threshold, another corenode may be triggered to assume servicing of the failed service (orservices).

Furthermore, such a network configuration is configured to allow sharingof resources among the core nodes. For example, one or more resources atone code node may be over-burdened, while other core nodes may berunning under capacity. In such a situation, some or all of the servicesfrom the over-burdened core node may be diverted to one or more othercore nodes. As such, the usage of all cores may be distributed in orderto maximize core node resource use and avoid a core node from being overcommitted.

It should be noted that any available path within network 500 may beused. For example, it may be more efficient or necessary for a failedservice at core node 405 c to be handled by core node 405 b, by passingthrough non-autonomous gateway 305 d. As such, network 500 providescompletely dynamic paths among the core nodes 405 and non-autonomousgateways 305. Furthermore, within network 500, any service can beprovided to any customer by any core at any time. In one embodiment,core node connectivity may be fully meshed at layer-2 using VPLS.

In one embodiment, because core node 405 is configured to provideend-to-end layer-2 connectivity across a network, core node 405 is ableto more easily peer with one or more public or private networks. Forexample, a public or private networks connect with non-autonomousgateway 305 d. The customers connected to non-autonomous gateways 305a-c can receive the content from the peering node connected tonon-autonomous gateway 305 d, as though the peering node was connecteddirectly to their respective non-autonomous gateways 305 a-c. This isdue, in part, to the end-to-end layer-2 connectivity and inter-nodeconnectivity. As such, the content provided by the peering node tocustomers connected with non-autonomous gateway 305 d is also providedto each of the other customers connected with non-autonomous gateways305 a-c. As such, peering at one node that is geographically dispersedfrom another nodes (or gateways) are able to provide access to thenetwork for which the first node is peered with. For example, by peeringwith a network in Dallas, network 400 has access to the network fromDenver (or anywhere else within network 400).

For example, a peering node in Dallas connected to a non-autonomousgateway 305 in Dallas can provide their content to customers in SanFrancisco (e.g., non-autonomous gateway 305 a), Denver (e.g.,non-autonomous gateway 305 b), Salt Lake (e.g., non-autonomous gateway305 c), by only connecting through a single drop point (i.e., Dallas).As such, a peering node providing content significantly increases thenumber of customers, without adding additional drop points. This isparticularly useful in a peering context because in order for a peeringrelationship to exist, the two networks need to be “peers” (i.e., berelatively equal in content and customer base). Network 500significantly increases the number of customers that the entityimplementing network 500 can represent to the potential peer, thusincreasing the likelihood of developing a peering (or equal)relationship.

Similar to a peering node, network 500 may connect with content servicenetwork (CSN) 240 and/or content delivery network (CDN) 240 through oneor more gateways 305. Like a peering relationship, CSN/CDN 240 providescontent and services to a network provider, and typically such CSN/CDNs240 are located at high traffic areas (e.g., New York, San Francisco,Dallas, etc.). Moving these CSN/CDNs 240 to more remote of morelocations is often not economical. Accordingly, network 500 allowsCSN/CDN 240 to connect at any gateway 305 or core node 405, and not onlyprovide the content and/or services to the customers at the connectedcore node 405 or non-autonomous gateway 305, but to customers within theentire network 500 connected to all non-autonomous gateways 305 and corenodes 405. Thus, the CSN/CDN 240 can connect at one drop point, andprovide content to all customers within network 500.

This, in part, is made possible by the end-to-end layer-2 connectivityof network 500. If the network was routed, then the customers notdirectly connected to the gateway or core node at the drop point for theCSN/CDN 240, are difficult to be on the same network and would not beable to receive the content and services. Furthermore, the redundancyscheme of network 500 provides a sufficient amount redundancy toaccommodate for such a large number of customers. Without the redundancyscheme of network 500, CSN/CDN 240 would not be able to be sufficientlysupported.

Additionally, network 500 is capable of utilizing out-of-band fail overnetworks for additional redundancy (e.g., out of band (OOB) network).Again, the out-of-band network can only be connected to onenon-autonomous gateway 305 or core node 405, but still provide theredundancy to any part of network 500. As such, network 500 need onlyconnect to the out-of-band network at one location in order to gain thebenefit of the out-of-band network throughout the entire network 500.

Furthermore, it should be noted that the configuration illustrated inFIG. 5A should not be construed as limiting, and any number ofvariations to the network architecture may be used. For example, anon-autonomous gateway may be connected to two core nodes and no othernon-autonomous gateways. Alternatively, the core nodes may not beinterconnected and/or a non-autonomous gateway may be placed between twocore nodes. As such any number of variations may be implemented.

FIG. 5B shows an illustrative communication link between a customerpremises equipment (CPE) 515 (i.e., customer, client, etc.) and Internet145, through a core node 405. In one embodiment, a request is generatedat CPE 515, which is sent to UT 510 and then transmitted over satellite520 to a base station (not shown) in an SMTS 215 at non-autonomousgateway 405. The request is switched at layer-2 though layer-2 switch310 and sent to a multilayer switch 210 at core node 405. Core node 405then sends the request to Internet 145 (or any other networkdestination). A response back to CPE 515 then would flow back throughthe network, in the same or similar manner.

FIG. 6 shows an embodiment of a satellite communications network 600that distributes autonomous gateways 205 and non-autonomous gateways 305across a number of geographically dispersed regions 605, according tovarious embodiments. In one embodiment, a first geographic region 605 a,a second geographic region 605 b and a sixth geographic region 605 frepresent environments where it is not cost-effective to providecommunications with core nodes 265. As such, these geographic regions605 are illustrated as having autonomous gateways 205. For example,autonomous gateways 205 may be used in island regions, geographicallyremote regions, regions with particular types of topologies (e.g., largemountain ranges), etc.

In contrast to the above-mentioned regions (geographic regions 605 a,605 b, and 605 f), a third geographic region 605 c, a fourth geographicregion 605 d, and a fifth geographic region 605 e indicate regions whereit is cost-effective to implement a core-based non-routed ground segmentnetwork 600. As illustrated, each non-autonomous gateway 305 is eitherdirectly or indirectly in communication with at least one core node 305(e.g., typically two core nodes). Other components may also be includedin the non-routed ground segment network 600. For example, additionalswitches 610, optical cross-connects 615, etc., may be used. Further,while the non-routed ground segment network 600 is configured to providepoint-to-point layer2 connectivity, other types of connectivity may alsobe implemented between certain nodes. For example, one or more VPLSnetworks may be implemented to connect certain nodes of the non-routedground segment network 600.

In various embodiments, core nodes 405 may be located on a new orexisting fiber run, for example, between metropolitan areas. In someconfigurations, the core nodes 405 may be located away from the majorityof spot beams (e.g., in the middle of the country, where much of thesubscriber population lives closer to the outsides of the country). Inalternative embodiments, core nodes 405 may be located near the majorityof spot means. Such spatial diversity between code nodes and subscriberterminals may, for example, facilitate frequency re-use of betweenservice beams and feeder beams. Similarly, non-alternative embodiments,core nodes 405 may be located near the majority of spot means. Suchspatial diversity between code nodes and subscriber terminals may, forexample, facilitate frequency re-use of between service beams and feederbeams. Similarly, non-autonomous gateways 305 may be located to accountfor these and/or other considerations.

It is worth noting that, twelve gateways (e.g., including bothnon-autonomous gateways 305 and autonomous gateways 205) areillustrated. If all were implemented as autonomous gateways 205, thetopology may require at least twelve gateway modules, routers, switches,and other hardware components. Further, various licensing and/or supportservices may have to be purchased for each of the autonomous gateways205. In some cases, licensing requirements may dictate a minimumpurchase of ten thousand licenses for each gateway module, which mayrequire an initial investment into 120-thousand licenses from the firstday of operation.

Using aggregated functionality in one or more core nodes 405, however,minimizes some of these issues. For example, by including four corenodes 405, each having a gateway module, and only three of the twelvegateways are autonomous gateways 205. As such, only seven gatewaymodules may be operating on the non-routed ground segment network 220.As such, only seven instances of each core networking component may beneeded, only seven licenses may be needed, etc. This may allow for asofter ramp-up and other features. As can be readily seen, such aconsolidation of the autonomous gateway functionality into fewer morerobust core nodes 405, is a significant cost savings.

Such a network as network 600 (also network 500) provides geographicallyexpansive network capabilities. Where other nationwide or worldwidenetwork are routed or connected at layer-2.5, layer-3, or higher (e.g.,MPLS, etc.), networks 500 and 600 are end-to-end layer-2 switchednetworks. Such a network, in essence, removes the geographicconstraints. Since, for example, if a customer was connected with one ofthe non-autonomous gateways 305 in geographic region 3 605 c, andanother customer was connected with one of the non-autonomous gateways305 in geographic region 5 605 e, the two customers would be configuredas though they were connected to the same switch in the same room.

FIG. 7 shows a block diagram of a system 700 for implementing mobilityacross satellite spot beams, according to various embodiments of theinvention. In one embodiment, system 700 may include core nodes 405 aand 405 b in communication with the Internet 125, CND/CSN 240 andMPLS/VPLS networks 245. Core nodes 405 a and 405 b are in communicationtogether at layer-2 of the OSI model. Furthermore, core node 405 a is incommunication, at layer-2, with non-autonomous gateway 305 a andnon-autonomous gateway 305 b, and core node 405 b is in communication,at layer-2, with non-autonomous gateway 305 c.

In a further embodiment, each of non-autonomous gateways 305 a-c servicespot beams at locations 710, 711, and 712, respectively. Mobile device705 is in communication with non-autonomous gateway 305 a at location710. In one embodiment, mobile device 705, upon connecting through aspot beam to non-autonomous gateway 305 a is assigned an IP address, andthe IP address is associated with a local area network (LAN). Mobiledevice 705 executes a number of applications (e.g., an internet browser,an email client, etc.), enterprise applications (VPN, exchange, etc.),etc. While the applications are being executed on mobile device 705,application sessions are established, and reliance on the assigned IPaddress is necessary by these applications. Further, in the event thatconnectivity is lost by the mobile device 705, or mobile device 705's IPaddress is changed, then application connectivity and the session wouldbe lost.

Assuming now that mobile device 705 is travelling in an airplane (in anautomobile on a train, on a ship, etc.), and mobile device 705 hasestablished a VPN session (or other application). As the airplanetravels from location 710 to location 711, the spot beam servicingmobile device 705 changes, and accordingly the non-autonomous gatewayservicing the spot beam changes from non-autonomous gateway 305 a tonon-autonomous gateway 305 b. As such, in order to maintain the same IPaddress, connectivity, the VPN session (in this example), etc., then ahandoff of the IP address for mobile device 705 occurs.

In one embodiment, the overlap of spot beam coverage at location 710 and711 is detected and the imminent transition of mobile device 705, and assuch from coverage under the first spot beam and the second spot beam isdetected. Once the imminent transition is detected and identified,non-autonomous gateway 305 a sends “handoff” message to core node 405 a,and then from core node 405 a to non-autonomous gateway 305 b. Each hopis at layer-2 of the OSI model and the messages are at layer-3 andabove, which allows the layer-3 protocol to be IP, DECNet, AppleTalk, orthe like. As such, each of non-autonomous gateway 305 a, core node 405a, and non-autonomous gateway 305 b are able to be on the same network(i.e., same subnet, same LAN, etc.).

Accordingly, as mobile device 705 moves to location 711, non-autonomousgateway 305 b is transitioned to maintaining connectivity for mobiledevice 705. Thus, connectivity is maintained, the same IP address ismaintained, and so forth. In a further embodiment, even if mobile device705 continues to travel to location 712, which is covered by a spot beamserviced by non-autonomous gateway 305 c, connectivity of mobile device705 is still maintained. Non-autonomous gateway 305 c is incommunication with core node 405 b, thus IP address and connectivity ofmobile device is still able to be maintained.

In this situation, once it is determined that mobile device 405 is goingto transition from the spot beam servicing location 711 to the spot beamservicing location 712, non-autonomous gateway 305 b sends anotification to non-autonomous gateway 305 c. The notification is sentat layer-3 (whereas the user traffic is sent at layer-2) fromnon-autonomous gateway 305 b to core node 405 a, core node 405 a to corenode 405 b, and then from core node 405 b to non-autonomous gateway 305c. Again, at no time during the handoff is connectivity to mobile device705 lost, or is the IP address of mobile device 705 changed. Thus,system 700 is configured to provide end-to-end continual connectivity,IP address, and session persistence across spot beams in a satellitenetwork.

Turning now to FIG. 8, which illustrates a system 800 for providingmobility access across satellite spot beams, according to one embodimentof the present invention. In one embodiment, system 800 includes amobile device 705 in communication with satellite 520. Mobile device 705is moving, for example, from west to east; however, it should be notedthat mobile device 705 could be moving in any direction. In oneembodiment, mobile device 705 is a Smartphone, a PDA, a laptop computer,a mobile computer, a cellular telephone, etc. Furthermore, mobile device705 may be travelling on a train, a plane, and automobile, etc.

Satellite 520 provides mobile device 705 with network connectivity at afirst location through a first spot beam 710. Satellite 520 is furtherconfigured to provide mobile device 705 with network connectivity at asecond location through spot beam 710 b. Accordingly, as mobile device705 moves from location to location, satellite 520 is able to providemobile device 705 with network connectivity at satellite 520's variousspot beams. It should be noted that while only two spot beams are shown,but many more spot beams and many more locations may be present, but forexplanatory purposes and ease of understanding, only two spot beams havebe shown in FIG. 8.

Once mobile device 705 has established connectivity with satellite 520,mobile device 705 receives session and/or IP information. For example,mobile device 705 is granted an IP address, which is likely a subnetaddress. In a typical system, when mobile device 705 moves from thecoverage of spot beam 710 a to spot beam 710 b, such session informationwould be lost, and a new session (or a new IP address) would beestablished at spot beam 711. Thus, mobile device 705 would loseconnectivity, change IP addresses, and would no longer be on the samenetwork (i.e., subnet, LAN, etc.) while the “handoff” from spot beam 710to spot beam 711 occurs.

According to one embodiment of the present invention, such a loss ofconnectivity as well as IP address and session information is avoidedusing the layer-2 connectivity between non-autonomous gateway 305 a,non-autonomous gateway 305 b, core node 405 a and core node 405 b. Inone embodiment, mobile device 705 is travelling, for example, in a trainfrom New York to San Francisco. For simplicity's sake, only two spotbeams have been shown, but in reality there would likely be many morespot beams between San Francisco and New York. As mobile device 705travels from the first location to the second location it becomenecessary for a handoff to occur from spot beam 710 to spot beam 711.

At that point, session and IP information stored at non-autonomousgateway 305 a is transmitted to core node 405 a and then from core node405 a to core node 405 b. Then, the session and IP information istransmitted from core node 405 b to non-autonomous gateway 305 b.Furthermore, the connectivity the entire way from non-autonomous gateway305 a to non-autonomous gateway 305 b is at layer-2 of the OSI model. Assuch, mobile device 705 is able to move from the first location to thesecond location without any change in connectivity. The handoff iscompletely transparent to mobile device 705. Mobile device 705's IPaddress remains the same, no break in connectivity occurs, applicationsessions are maintained, etc.

Furthermore, satellite 105 establishes a connection with mobile device705 at the second location using spot beam 710, the session informationfrom mobile device 705's session through spot beam 711 is maintained forthe connection at the second location with spot beam 711. Accordingly,mobile device 7052 is unaware that any handoff has occurred, and allsession connectivity and information is maintained.

Referring now to FIG. 9, which illustrates a method 900 of providingmobility access across satellite spot beams, according to one embodimentof the present invention. At process block 905, network access to amobile device through a first spot beam at a first location is provided.The satellite is further in communication with at least a first andsecond gateway, which are in turn in communication with at least a firstand second core node.

At process block 910, an indication is received that the mobile deviceis moving from the first location to a second location, where the secondlocation is serviced with a second spot beam. Accordingly, at processblock 915, the first gateway connects with a second gateway at a layer-2through the first and second core nodes. Due to the fact that theconnectivity from the first gateway to the first core node, the firstcore node to the second core node, and then the second core node to thesecond gateway is at layer-2, and the mobile device is able to maintainthe same IP address through the handoff and any application and/orsession information (process block 920).

Thus, at process 925, the mobile device at the second location throughthe second spot beam established access to the network with the same IPand/or session of the mobile device while at the first locationconnected to the first spot beam. Hence, no connectivity break, no lossof session, no loss IP information, etc., occurs.

FIG. 10 is a simplified block diagram illustrating the physicalcomponents of a computer system 1000 that may be used in accordance withan embodiment of the present invention. This diagram is merely anexample, which should not unduly limit the scope of the claims. One ofordinary skill in the art would recognize many variations, alternatives,and modifications.

In various embodiments, computer system 1000 may be used to implementany of the computing devices of the present invention. As shown in FIG.10, computer system 1000 comprises hardware elements that may beelectrically coupled via a bus 1024. The hardware elements may includeone or more central processing units (CPUs) 1002, one or more inputdevices 1004 (e.g., a mouse, a keyboard, etc.), and one or more outputdevices 1006 (e.g., a display device, a printer, etc.). For example, theinput devices 1004 are used to receive user inputs for procurementrelated search queries. Computer system 1000 may also include one ormore storage devices 1008. By way of example, storage devices 1008 mayinclude devices such as disk drives, optical storage devices, andsolid-state storage devices such as a random access memory (RAM) and/ora read-only memory (ROM), which can be programmable, flash-updateableand/or the like. In an embodiment, various databases are stored in thestorage devices 1008. For example, the central processing unit 1002 isconfigured to retrieve data from the database and process the data fordisplaying on a GUI.

Computer system 1000 may additionally include a computer-readablestorage media reader 1012, a communications subsystem 1014 (e.g., amodem, a network card (wireless or wired), an infra-red communicationdevice, etc.), and working memory 1018, which may include RAM and ROMdevices as described above. In some embodiments, computer system 1000may also include a processing acceleration unit 1016, which can includea digital signal processor (DSP), a special-purpose processor, and/orthe like.

Computer-readable storage media reader 1012 can further be connected toa computer-readable storage medium 1010, together (and, optionally, incombination with storage devices 1008) comprehensively representingremote, local, fixed, and/or removable storage devices plus storagemedia for temporarily and/or more permanently containingcomputer-readable information. Communications system 1014 may permitdata to be exchanged with network and/or any other computer.

Computer system 1000 may also comprise software elements, shown as beingcurrently located within working memory 1018, including an operatingsystem 1020 and/or other code 1022, such as an application program(which may be client application, Web browser, mid-tier application,RDBMS, etc.). In a particular embodiment, working memory 1018 mayinclude executable code and associated data structures for one or moreof design-time or runtime components/services. It should be appreciatedthat alternative embodiments of computer system 1000 may have numerousvariations from that described above. For example, customized hardwaremight also be used and/or particular elements might be implemented inhardware, software (including portable software, such as applets), orboth. Further, connection to other computer devices such as networkinput/output devices may be employed. In various embodiments, thebehavior of the view functions described throughout the presentapplication is implemented as software elements of the computer system1000.

In one set of embodiments, the techniques described herein may beimplemented as program code executable by a computer system (such as acomputer system 1000) and may be stored on machine-readable media.Machine-readable media may include any appropriate media known or usedin the art, including storage media and communication media, such as(but not limited to) volatile and non-volatile, removable andnon-removable media implemented in any method or technology for storageand/or transmission of information such as machine-readableinstructions, data structures, program modules, or other data, includingRAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM,digital versatile disk (DVD) or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to store ortransmit the desired information and which can be accessed by acomputer.

While principles of the disclosure have been described above inconnection with specific apparatuses and methods, it is to be clearlyunderstood that this description is made only by way of example and notas limitation on the scope of the disclosure. Further, while theinvention has been described with respect to exemplary embodiments, oneskilled in the art will recognize that numerous modifications arepossible. For example, the methods and processes described herein may beimplemented using hardware components, software components, and/or anycombination thereof. Further, while various methods and processesdescribed herein may be described with respect to particular structuraland/or functional components for ease of description, methods of theinvention are not limited to any particular structural and/or functionalarchitecture but instead can be implemented on any suitable hardware,firmware and/or software configuration. Similarly, while variousfunctionality is ascribed to certain system components, unless thecontext dictates otherwise, this functionality can be distributed amongvarious other system components in accordance with different embodimentsof the invention.

Moreover, while the procedures comprised in the methods and processesdescribed herein are described in a particular order for ease ofdescription, unless the context dictates, otherwise, various proceduresmay be reordered, added, and/or omitted in accordance with variousembodiments of the invention. Moreover, the procedures described withrespect to one method or process may be incorporated within otherdescribed methods or processes; likewise, system components describedaccording to a particular structural architecture and/or with respect toone system may be organized in alternative structural architecturesand/or incorporated within other described systems. Hence, while variousembodiments are described with-or-without-certain features for ease ofdescription and to illustrate exemplary features, the various componentsand/or features described herein with respect to a particular embodimentcan be substituted, added and/or subtracted from among other describedembodiments, unless the context dictates otherwise. Consequently,although the invention has been described with respect to exemplaryembodiments, it will be appreciated that the invention is intended tocover all modifications and equivalents within the scope of thefollowing claims.

What is claimed is:
 1. A method of satellite communication, the methodcomprising: providing a communication service for an aircraft by a firstgateway servicing a first spot beam having a first spot beam coveragearea that includes a location of the aircraft; assigning, to a device onthe aircraft, an Internet Protocol (IP) address; communicating, via thefirst gateway servicing the first spot beam, first session trafficaccording to the IP address, the first session traffic associated withan application executing on the device; identifying an imminenttransition of the aircraft from being provided the communication servicevia the first spot beam to being provided the communication service viaa second spot beam that is serviced by a second gateway; sending, fromthe first gateway to the second gateway, a handoff message for handoffof the IP address for the device from the first gateway to the secondgateway; and communicating, upon the transition of the aircraft to beingprovided the communication service via the second spot beam serviced bythe second gateway, second session traffic associated with theapplication via the second gateway servicing the second spot beam, thesecond session traffic being communicated according to the IP address.2. The method of claim 1, further comprising: switching the firstsession traffic between a content network and the first gatewayaccording to the IP address; and switching the second session trafficbetween the content network and the second gateway according to the IPaddress.
 3. The method of claim 1, wherein the IP address is of a subnetcomprising the first gateway and the second gateway.
 4. The method ofclaim 1, wherein the first gateway and the second gateway are incommunication at layer-2 (L2) of the OSI model.
 5. The method of claim1, wherein the handoff message comprises a message at layer-3 (L3) ofthe OSI model.
 6. The method of claim 1, wherein the first sessiontraffic is communicated using a layer-3 (L3) protocol.
 7. The method ofclaim 1, wherein the device is one of a smartphone, a PDA, a laptopcomputer, a mobile computer, or a cellular telephone.
 8. The method ofclaim 1, wherein each of the first gateway and the second gateway areprovided a service for the first session traffic by a core node.
 9. Themethod of claim 8, wherein the service comprises at least one of anauthentication service, an acceleration service, a file transferservice, a traffic shaping service, a dynamic host configurationprotocol service, a domain name system (DNS) service, a network loggingservice, or an encryption service.
 10. A system for providing mobilityacross satellite beams, the system comprising: a first gateway servicinga first spot beam having a first spot beam coverage area, the firstgateway providing a communication service for an aircraft at a locationwithin the first spot beam coverage area, the first gatewaycommunicating first session traffic according to an IP address assignedto a device on the aircraft, the first session traffic associated withan application executing on the device; and a second gateway servicing asecond spot beam, wherein the first gateway identifies an imminenttransition of the aircraft from being provided the communication servicevia the first spot beam to being provided the communication service viathe second spot beam and sends a handoff message to the second gatewayfor handoff of the IP address for the device from the first gateway tothe second gateway, and wherein the second gateway communicates, uponthe transition of the aircraft to being provided the communicationservice via the second spot beam serviced by the second gateway, secondsession traffic associated with the application, the second sessiontraffic being communicated according to the IP address.
 11. The systemof claim 10, further comprising a ground segment network coupled withthe first gateway and the second gateway, wherein the ground segmentnetwork: switches the first session traffic between a content networkand the first gateway according to the IP address; and switches thesecond session traffic between the content network and the secondgateway according to the IP address.
 12. The system of claim 10, whereinthe IP address is of a subnet comprising the first gateway and thesecond gateway.
 13. The system of claim 10, wherein the first gatewayand the second gateway are in communication at layer-2 (L2) of the OSImodel.
 14. The system of claim 10, wherein the handoff message comprisesa message at layer-3 (L3) of the OSI model.
 15. The system of claim 10,wherein the first session traffic is communicated using a layer-3 (L3)protocol.
 16. The system of claim 10, wherein the device is one of asmartphone, a PDA, a laptop computer, a mobile computer, or a cellulartelephone.
 17. The system of claim 10, further comprising: a core nodecoupled with each of the first gateway and the second gateway, whereinthe core node provides a service for each of the first gateway and thesecond gateway.
 18. The system of claim 17, wherein the servicecomprises at least one of an authentication service, an accelerationservice, a file transfer service, a traffic shaping service, a dynamichost configuration protocol service, a domain name system (DNS) service,a network logging service, or an encryption service.